home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000101_owner-urn-ietf _Thu Nov 7 12:18:10 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  7KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA00212 for urn-ietf-out; Thu, 7 Nov 1996 12:18:10 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA00207 for <urn-ietf@services.bunyip.com>; Thu, 7 Nov 1996 12:18:08 -0500
  3. Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA23013  (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 12:17:24 -0500
  5. Received: from ifi.unizh.ch by josef.ifi.unizh.ch 
  6.           id <00910-0@josef.ifi.unizh.ch>; Thu, 7 Nov 1996 18:15:35 +0100
  7. Subject: Re: [URN] I18N does not belong in URNs
  8. To: moore@cs.utk.edu
  9. Date: Thu, 7 Nov 1996 18:15:34 +0100 (MET)
  10. Cc: tallen@fsc.fujitsu.com, urn-ietf@bunyip.com
  11. In-Reply-To: <199611062032.PAA10773@ig.cs.utk.edu> from "Keith Moore" at Nov 6, 96 03:32:28 pm
  12. Mime-Version: 1.0
  13. Content-Type: text/plain; charset=US-ASCII
  14. Content-Transfer-Encoding: 7bit
  15. Content-Length: 5192
  16. From: Martin J Duerst <mduerst@ifi.unizh.ch>
  17. Message-Id: <"josef.ifi..235:07.10.96.17.15.36"@ifi.unizh.ch>
  18. Sender: owner-urn-ietf@services.bunyip.com
  19. Precedence: bulk
  20. Reply-To: Martin J Duerst <mduerst@ifi.unizh.ch>
  21. Errors-To: owner-urn-ietf@bunyip.com
  22.  
  23. Keith Moore wrote:
  24.  
  25. >Perhaps.  I don't have as big a problem with this, as long as
  26. >there's a discipline about how they are assigned that prevents
  27. >URNs from being used as search strings.  That's my main worry.
  28. >(URNs are also supposed to be transcribable, but I recognize that
  29. >only a very small set of characters is transcribable by everyone
  30. >on the planet.)
  31.  
  32. For "everyone", you might have to limit it to X and O, or even
  33. X and XX :-).
  34.  
  35. Just an additional example: Think about number plates of cars.
  36. Lots of non-ASCII characters there all over Asia.
  37.  
  38. >> So for grandfathering, we have two choices.
  39. >> 
  40. >> 1) We interpret it as "direct grandfathering of characters",
  41. >>     in which case we have to allow a really wide range
  42. >>     of characters (i.e. ISO 10646).
  43. >> 2) We interpret it as "indirect grandfathering", in which
  44. >>     case the digits, or whatever small set, will be
  45. >>     enough.
  46. >
  47. >I suspect there will be some of each.
  48.  
  49. I wouldn't mind "some of each", if this means "about the same
  50. amount for everybody on the world". If it comes to mean "a lot
  51. for English-speaking, but very little for the rest of the world",
  52. I would have to strongly disagree.
  53. In theory, I could immagine making a worldwide search of
  54. suitable namespaces, and limiting the characters to those
  55. appearing in such namespaces. But I guess we would quickly
  56. end up with all the major alphabets completed, and the work
  57. deciding which of the ~20,000 CJK ideographs is used in a
  58. naming scheme, and which not, would not be very rewarding.
  59.  
  60.  
  61. >But we want the transformations
  62. >from "old identifier" to URN to be simple and easy to remember.
  63.  
  64. Back to user-friendliness, in some sense. I have no problems
  65. about this. But again, I wouldn't like it if "simple and easy
  66. to remember" means that English speaking people just have to
  67. type them in, whereas people in the rest of the world, for
  68. namespaces that are currently in use there, need list of
  69. correspondences they have to look up or remember constantly.
  70.  
  71.  
  72. >> Choosing ASCII only as for URLs would be very unfair cheating.
  73. >
  74. >If the names aren't human meaningful, I don't see what you're
  75. >complaining about.
  76.  
  77. If I were sure the names would not be meaningful, I would not
  78. have much reason to complain. But the URL example shows that
  79. restricting people from becomming meaningful is very hard if
  80. not impossible.
  81.  
  82. You may agree with the above point, or you may disagree. But
  83. either way, ASCII only is unfair. If you think that naming
  84. schemes, protocols, standards, some review board, or whatever,
  85. can assure that no meaningful stuff is created, then there
  86. is no reason to restrict to ASCII. One should assume that
  87. Japanese, Russians, Chinese, or whoever, can be as disciplined,
  88. or as tighly controlled, as the English-speaking part of the
  89. world. On the other hand, if you think that namespaces
  90. will get meaningful because of people's nature, and you
  91. think it is a bad thing that has to be avoided, there is
  92. no other choice but to limit ourselves to the decimal digits
  93. and maybe two or three other characters.
  94.  
  95.  
  96.  
  97. >> >> I definitely hate to see i18n just being moved around and delayed
  98. >> >> by some people. With UTF-8 in URNs, we have made great progress.
  99. >> >
  100. >> >No, this is a big step backward.  Just because there is a new layer
  101. >> >being defined doesn't mean that I18N belongs there.  
  102. >> >
  103. >> >I18N *is* important  -- and I'd be happy to see a draft document or 
  104. >> >draft charter for a working group to define a protocol (say an extension
  105. >> >of http/html) to resolve human-friendly names into URNs or URLs.
  106. >> 
  107. >> Why is there a need for an additional protocol layer?
  108. >> There is no need currently for English, is it?
  109. >
  110. >Yes, there is.  Human-friendly names are inherently ambiguous,
  111. >and have ambiguous meanings which require a human being to untangle.
  112. [examples removed]
  113.  
  114. >URNs should be precise enough that a human isn't required to
  115. >disambiguate the result.
  116.  
  117. I know your examples. But there can be a great deal of human-friendliness,
  118. without any need for ambiguity. URLs such as http://www.ibm.com
  119. or http://www.icrc.org are examples. My brother, who works at ICRC in
  120. Geneva, recently called me. Before he was able to tell me how I could
  121. reach him by email, I had the ICRC home page on my browser, and had
  122. found the generic email address explanations, and had sent him a mail.
  123. Of course, I'm an expert, but there are many people with less Web
  124. experience and technical expertise who could do that.
  125.  
  126. If it can be that human-friendly, and that unambiguous, I don't know why
  127. I should go to a search service to find the ICRC. And I don't know
  128. why people that use other scripts should go though a serach service,
  129. while English speaking users don't have to do so.
  130.  
  131.  
  132. >> And I don't want to have to search through long lists
  133. >> of possible answers just because I use Japanese, whereas
  134. >> I will get one immediate answer for English.
  135. >
  136. >The point is that you will often get multiple answers for English.
  137. >English names are no more precise than names in other languages.
  138.  
  139. No, but English can be used in URLs, and I get an unambigous
  140. result if there is one, in due time. In Japanese, even if the
  141. result would be unambiguous, I currently can't get it fast and
  142. easily.
  143.  
  144.  
  145. Regards,    Martin.